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Xerox Palo Alto Research Center (PARC): 


PARC is a research facility of the Xerox Corporation. It is involved in 
research in the physical sciences, computer hardware and software systems 
and the computer sciences in general. These latter include computer 
architecture, interactive graphics, operating systems, programming 
research, and natural language understanding systems. The Computer Science 
Laboratory (CSL) of PARC currently numbers thirty technical and support 
staff. 


INTRODUCTION 


The ARPA contract reported herein concerns the development of an NLS-like 

[1] display-oriented text-editing system supporting multiple users on a 
minicomputer configuration. The research also aims to use this development 
as a source of suggestions and a gauge for a set of software engineering 
techniques which are intended for large and complex software systems. 

The originally proposed (two year) research plan included the following 
major steps: 

(1) A reimplementation (including redesign) of the TENEX-based MLS 
system in the Modular Programming System (MPS)—MPS is an ongoing, 
separate research program which has been developed collaboratively 
by PARC and SRI-ARC. 

(2) Bootstrapping of MPS to a suitable minicomputer; 

(3) Development of a mini operating system (mini-OS) to support 
multiple MPS programs, a file system and a virtual memory 
(probably with little or no assistance from any memory mapping 
hardware); 

(4) Transfer of NLS (written in MPS) from a PDP-10 to a minicomputer 
by recompilation—with as little rewriting as possible. 

(5) "Tuning" of the experimental mini NLS (xNLS) to support as many 
users as possible. 
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The first year of this plan has primarily dealt with the following specific 
tasks: 

(a) initial evaluations of the problems involved in putting a large 
multi-user system like NLS on a small computer and specification 
of suitable minicomputer hardware, 

(b) redesign of NLS to 

(1) take advantage of SRI-ARC's considerable experience with 
the system; 

(2) use and evaluate the features of MPS for large systems; 

(3) provide for an NLS which would be amenable to being 
distributed over the ARPANET (e.g., with display "front 
ends" at remote locations), 

(c) development of an ARPANET protocol for providing access to NLS 
over the network from suitable display terminals. 







SECTION I 


Large Systems on Small Machines : 

Although the exact forms which computer hardware may take in the future are 
hard to predict, there are a number of trends which are evident: 

(1) processor speed on the order of 1 microsecond per instruction is a 
fact; 

(2) the cost of digital logic has dropped by a factor of two every 
five years; 

(3) memory determines the cost of a minicomputer to a much greater 
extent than its CPU. 

These trends must interact with some observed facts about large, 
interactive systems such as NLS: 

(1) The body of code for the system is large: NLS is composed of a 

number of wel1-integrated, sophisticated facilities each of which 
is in itself fairly complex; 

(2) the large subsystems of NLS interact only infrequently (relative 
to the interactions within a subsystem) and over fairly narrow 
interfaces; 

(3) when the user is specifying the next action to be performed by 
NLS, very little state information and processing are necessary to 
respond to him, but that response must be immediate. (Character 
echoing or command recognition and feedback are examples.) 

These two sets of observations have led to some design decisions for xNLS. 
Since most minicomputers are about as fast at manipulating text as a PDP-10 
(the machine on which NLS is currently implemented), the size of the xNLS 
software and the size of the memory on the minicomputer will be the hardest 
constraint on system performance. There are a number of means by which 
this constraint can be eased: 

(1) Implement only the most frequently used parts of NLS on the mini 
(e.g. its text-editing facilities) and access other system 
functions such as hard-copy output formatting, automatic document 
distribution and classification by using the parent NLS over the 
ARPANET; 

(2) Provide for a virtual memory underlying MPS but lock the portion 
of a user's process into memory which is required for quick 
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response during user input; this saves swapping overhead without 
wasting much primary memory since the state needed is usually very 
small (certainly less than 100 words). An underlying segmentation 
scheme for automatic overlaying of running MPS programs is 
described in [6], 

(3) Obtain minicomputer hardware which will help to implement a 

virtual memory: this includes some memory mapping hardware and a 
reasonably large, high-speed swapping device. 

(1*) Since computing speed is much less a constraint than memory, a 
trade can be made: compile MPS programs into a very compact 
interpretive code and run as much of NLS as possible in this way; 
some recent work by Deutsh [2] indicates that such a technique 
can compact programs by a factor of 2 to 5. This should lower the 
swapping rate accordingly (unless the interpretive slowdown backs 
up the system and artificially causes thrashing). 

A Minicomputer Configuration for xNLS : 

The above hardware and software considerations led to the selection of the 
following minicomputer configuration: 

A 16-bit, 800 nanosecond CPU 

A 64k l6-bit, 800 nanosecond memory 

A simple mapping device for accessing memory in pages 

A high speed, 1.25 Mword, fixed head disk (expandable to 2.5 
Mwords); its transfer rate is 275,000 words/second and it operates 
over a DMA channel 

The original hardware mapping device design was a simple addition to a Data 
General NOVA 800 with 4k memory boards and operated on 4k word pages. It 
was designed by E. McCreight of PARC and required about 15 standard 
integrated circuits. Since then, minicomputer manufacturers have provided 
their own memory mapping hardware and main memories as large as 128k words. 

The fixed head disk, main memory, and memory mapping device are all 
attempts to overkill the memory constraint discussed earlier. Such a 
system can be purchased commercially for approximately $50k. If it could 
support ten NLS users, then the cost per user, including a reasonable 
terminal ($3000 to $5000) would be $8000 to $10000; if it could only 
support five users, this range would be raised to $13000 to $15000. The 
trends in hardware may very well indicate that it would be better to build 
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single user systems (one man, one computer) if the cost of the multi-user 
system is this large. 

What problems would go away if the system were to serve only a single user? 
Hardly any. The size of NLS would diminish not at all, and although the 
entire bandwidth of the swapping channel would be available to a single 
user, the size of main memory would have to be smaller (because of the 
price ceiling of $ 1 Ok to $15k) and the swapping rate would therefore be 
higher. Computing power, however, would be a freer resource than under a 
multi-user system. Other than this, all the problems of a large system 
still remain: a file system, memory management and a mini-OS would still 
be necessary, and the system would still have to be maintained and changed 
over time. Thus, the multi-user requirement for xNLS could be elided with 
almost no alteration to the remainder of the project: the results pertinent 
to large systems on small machines and to a redesign of NLS would not be 
affected. 


File Storage for xNLS : 

Long term file storage in xNLS can be accomplished in a number of ways 
without requiring a large disk system and its concomitant management 
overhead. Frequently accessed, small to medium sized files (0 to 20 page 
documents) can be kept on the swapping disk along with system programs and 
working storage without exhausting the storage. Larger files which are 
accessed often could be stored at some ARPANET site with a suitable file 
facility. Such a file could either be transmitted in its entirety to the 
xNLS site when needed or "paged" over the network. In the latter case, 
xNLS would request a given page at most once, but might transmit "dirtied" 
(altered) pages back to the file source many times. Lastly, files might be 
kept on removable media (such as tape cassettes, tape cartridges, or floppy 
disks) and transferred to the swapping disk when needed. This could be 
especially useful in a single-user system. The network "paging" technique 
can also be used with some removable media, both for speed and for 
minimizing work loss resulting from xNLS system failures. 
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SECTION II 


The NLS Protocol ; 

The NLS Display is divided into a number of rectangular display areas 
(DAs). A DA may contain a number of STRINGS at a selected set of (X,Y) 
positions in the DA. A DA is named by a DAID, which is a 9-bit number. 

The size of a DA is given by two parameters: NSTRS, the height (in units 
of lines) and NCHARS, the maximum number of characters in a line in the 
display area. Other attributes of a DA include the coordinates of its 
lower left-hand corner, called (XB0T,YB0T), the separation between lines, 
called DY (the units of DY, X and Y are a function of a particular display 
device), and the width of a character, called HINC (also in the units of 
the display device). A typical DA as used on an IMLAC PDS-1 display 
computer [ 3 ] is illustrated in figure 1 with its DA parameters illustrated 
(this NLS protocol has been implemented for IMLAC displays and is used at a 
number of ARPA sites). Characters as used on the IMLAC are 7x9 points with 
2 points of horizontal spacing between characters and 9 points between 
lines. This DA may hold at most NSTRSxNCHARS=30x73=2190 characters. 


=73x9 points 


1 2 


(656,539) 


4 5 6 7 8 9 


1 


7777 

0123 


0 1 



18*30 


=540points 



(656,0) 


Figure 1 Parameters for a Typical DA 
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DAs may be created and destroyed dynamically. When one is created, it is 
given an integer "name" called a DAID by the host computer (i.e. not by the 
display processor which is obeying the protocol) which is used in all 
operations relevant to DAs. Those operations are: 

Create DA 

Destroy DA 

Suppress DA (stop displaying all strings therein) 

Suppress and clear DA 

Restore DA (cause strings in it to be displayed) 

DAs may overlap, subject to some rules about which strings will show in the 
regions of overlap. A feasible layout of DAs on a display screen is shown 
in figure 2. Note that DAs may overlap to any extent, and that there is no 
requirement that the entire display screen be covered by DAs. 



Figure 2 Sample Layout of DA's on a Display Screen 
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The only entities which may be put into a DA are strings: a string is a 
sequence of 7"bit ASCII bytes. A string has a name called an STRID (a 
number in the range [0,177B] -- "B" suffixed to a number indicates octal 
notation) which is local to the DA in which it lives. This name is 
assigned by the host computer when the string is initially transmitted. 

The manipulations which may be done to strings are 

(a) New string to position (X,Y) in DAID with given STRID 

(b) Suppress display of a string in a DA 

(c) Restore display of a string in a DA 

(d) Suppress displaying of a string and delete it from the DA 

Command (a) may also be used to move a string from one position to another 
without retransmitting the entire string: this is a great economizer of 
bandwidth. 

If two DAs overlap, the strings in both will be displayed unless either one 
or the other DA is suppressed or strings in the overlap areas of the DAs 
are selectively suppressed. Overlapping DA's are used by NLS for 
displaying user-requested status information by selectively suppressing the 
strings in one DA in order to display the necessary information in an 
overlying DA. When the user no longer needs the information, the overlying 
DA is completely deleted and the suppressed strings in the underlying one 
are restored. This is especially important for fully utilizing the display 
surface area without permanently allocating DAs for infrequently required 
information. 

Sequential Display Areas : 

The NLS protocol allows the display processor to act as a simple teletype 
so that the normal typewriter communications methods in many systems may be 
used without change. A DA which can accept such communication is called a 
sequential display area (SDA), and there is assumed to be one distinguished 
SDA which simulates normal typewriter output for the system which supports 
NLS (e.g. the TENEX system used at SRI-ARC). This SDA, hereafter called 
the TTYSDA must be the initial, "current" DA when communication between the 
NLS host and the display is initiated. 

The distinguishing features of an SDA (as contrasted with a DA) are as 
follows: 

(a) The last character in a line may be deleted; in a 
normal DA the minimum entity which can be 
manipulated is an entire string; thus, to delete 
the last character in a line in a DA, the entire 
line minus its last character must be transmitted 
to replace itself. 
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(b) The lines in an SDA are automatically scrolled up 
one line when the SDA is full and a new line is 
added at the bottom 

(c) An SDA is specified just like a DA. The display 
processor, however, interprets some characters 
whose destination is an SDA in a special way: 
carriage-return (015B) and line-feed (012B) cause 
actions comparable to those evoked on a typewriter 
terminal. Carriage-return means that the next 
character to the SDA will be "written" at the 
beginning of the current line; line-feed increments 
the pointer to the current line or causes the lines 
in the SDA to "scroll" up one line (in the case 
that the SDA is full when the line-feed character 
is received). 

(d) When an "unescorted character" is received by the 
display processor, it is always placed in the 
TTYSDA. It may also be written into one or two 
extra "default" SDAs if they have been so enabled. 

There are a number of protocol commands which are applicable to the TTYSDA: 

(a) Enable TTYSDA and suppress the display of all other 
DAs. (the display is then said to be in "TTY 
mode") 

(b) Suppress TTYSDA and restore the display of any DAs 
that were suppressed by the last "Enable TTYSDA". 

(the display is then in "Display mode") 

(c) Unescorted characters always go to the TTYSDA and 
any associated default SDAs even if the TTYSDA is 
not enabled. Moreover, if the TTYSDA is 
suppressed, the default SDAs need not be. This is 
useful for providing a small "TTY window" even when 
the TTYSDA is suppressed. 


Terminal Input : 

The input devices for NLS include a typewriter keyboard, a pointing device 
called a mouse (with three push buttons B2, B1 and B0 on it) and a device 
called a keyset (or, more descriptively, a "five-finger chord keyset"). 
These are all described fully in [1], The display processor must 
"continuously" display a string on the screen at the position determined by 
(x,y) coordinates read from the mouse. This string (usually a single 
character) is called the cursor and "tracks" the mouse. The five-finger 
keyset acts like a replacement for the keyboard, but in order to key more 
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than 31 possible characters, two of the three buttons on the mouse (B2 and 
Bl) are used as "case-shift" buttons in conjunction with it. Appendix B 
gives the keyset/ASCI I correspondences for (B2, B1)=(0,0), (0,1) and (1,0). 

In TTY mode the display will send a single ASCII character per keystroke 
(keyboard or keyset "chord") to the NLS host; this is called "short 
character mode" (SC-mode). 

The display processor can also operate in a "long character mode" (LC- 
mode): this provides mouse coordinates to the NLS host when necessary. 
Short, unescorted ASCII characters are still sent to the NLS host when the 
display is in LC-mode under the following circumstances: 

(51) the user input is a character from the keyboard and is not an 
ASCII control character (i.e. is not in the range [0,37B]); 

(52) the input is a single character "chord" from the five-finger 
keyset. 

Some translation is done on keyset characters. If k is the 5-bit number 
corresponding to a keyset chord then the character sent to the NLS host is 

(a) (k+l40B) if k is in the range [1,32B] (i.e. lowercase alphabetic) 

(b) otherwise, a chord in the range [33B.37B] is translated according 
to the following table: 


k 

Character Sent 

Printed form 

33B 

54B 

p 

34B 

56b 

• 

35B 

73B 

• 

p 

36B 

77B 

? 

37B 

40B 

SPACE 


Long characters are sent to the NLS host in the following circumstances: 

(LI) the state of one or more mouse buttons changes (either because one 
or more are depressed or released); 

(L2) an ASCII control character is typed on the keyboard. 

The formats of long characters are 

(a) in case (LI), a seven byte string is sent to the NLS host: 

BMSG 45B (buttons+lOOB) XX YY 

= 034B). 


(Where BMSG 





The state of the buttons B2, B1 and BO are encoded into a single 
octal digit with B2 as its most significant bit. XX and YY are 
each two bytes long; they represent 12-bit numbers (6 bits in each 
8-bit byte) and are the coordinates of the mouse at the time the 
mouse buttonb changed. 

(b) case (L2) has two subcases. If the control character is one of 
the NLS special control characters (tB [Center Dot], +D (Command 
Accept), or fX [Command Delete]),character sent is 

BMSG A5B (character+lAOB) XX YY 

which is similar to that sent for case (LI). Otherwise, the long 
character has the form 

BMSG 41B (character+l40B) 

Thus, mouse coordinates only accompany mouse button changes or NLS 
control characters: their presence is indicated by the **5B 
following the ESC character. 

In order to provide a reasonable interface between the characters sent by 
the display and the NLS system, the current NLS host, TENEX, performs some 
transformations on the characters received by it before they are made 
available to NLS. These basically make coordinates available "on request" 
to NLS and integrate sequential mouse button changes (so that simultaneous 
actuations are not necessary) before presenting the changed state to NLS. 
Also, mouse button states and characters are only obtained by direct 
request from NLS (and therefore, not asynchronously). 

This way of sending mouse coordinates to the NLS host may seem somewhat 
wasteful of bandwidth; however, it guarantees that the coordinates for a 
pointing operation by the user will be the ones he specified when he 
pressed button BO (called the select button or "Command Accept") on the 
mouse. If this were not done, and NLS had to request mouse coordinates 
after deciding that it needed them, (random) delays in NLS's response time 
would cause it to acquire coordinates corresponding to where the user was 
pointing when NLS made the request rather than the ones available when he 
made the pointing selection; this would be a totally unacceptable 
situation. Short character or long character mode is set by the NLS host's 
sending a suitable command to the display; it is not automatically 
associated with TTY mode or display mode, which have to do with the 
messages sent to the display from NLS. 


12 




I h '\t string which is displayed as the mouse is tracked is specified 

by the NLS host and can be dynamically changed: NLS uses this feature to 
indicate when the mouse can be used to select something on the screen (the 
cursor is displayed as a "+") and when it cannot (a "+" is displayed). 

NLS allows two separate displays to share a common view so that two people 
may view the same information even if they are remote from one another. 

his includes displaying each person’s mouse cursor on the other person's 
screen so that they can each refer to objects on the other's display. To 
accomplish this, the NLS host can request that the display processor send 
mouse coordinates continuously" so that they may be displayed on the 
remote screen. Actually, the NLS host may only request that the mouse 
coordinates be sent every DT milliseconds if either coordinate has changed 
by an airount greater than DXY (the absolute minimum DT is 6/b where 

tra "? misslon ,ine in bytes/sec, the value "6" comes from the 
ract that the coordinates are sent as the six byte stream 

BMSG 44B X X Y Y, 

which is analogous to long characters as described above. For the ARPANET 

us^lOOo'hT ' S a° |" ,n,second s because all messages shorter than 1000 bits 

Thus °nT— and i h nvC e J W0 ^ k (burst) bandwidth is 50000 bits/second). 

^ark:? T_2 ? m !h C and ° XY= ’ ' S the f ' neSt gra!n a,,owed continuous 
tracking of the remote cursor by the NLS host. The host can, of course 

f„rn ? q ?! St X at the continuous transmission of mouse coordinates be 

in deta in I S 5- C 'I' C ° rmatS ° f the commands for doing this are given 
in detail in Appendix A. 
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SECTION I I I 


The NLS Redes I 


an 


A redesign of NLS has begun under the auspices of SRI-ARC with 

outnnld^irW 157 ? er °* PARC * The motivations for this effort have been 
Tt 1 '? ^.s report; they are also given in detail in "A Look 

at the MPS Conversion [4] which describes the areas of NLS requiring 
redesign and the problems of the current NLS implementation. Thus far. the 
design has concentrated on the parts of NLS which are associated with the 

“!* r " 1terface = ?'»>'«* and feedback, user command specification 

and the command language facilities themselves. 

The system components which deal with the hardware realities of a qiven 
display have been segregated from the "ideal" (or at least, normalized) 

?n S sIr?* ° n' Ch NLS ,nt ? rfaces * This has used the NLS protocol described 
d?so?a! 1 as a starting point and the design adopts the view that the 
splay is always accessed via an interface like the ARPANET protocol, 
deed, one of the design "meta-decisions" for the redesigned NLS (NLS*) 

to far^-Tr th ®. sys 5® m shou,d be severable at a number of places in order 
to facilitate a distributed implementation, with as much (or as little) 

front-end processing done remotely as is desirable. This aims partly at 
the parent NLS to xNLS relationship discussed in Section I, and par ly It 
cleanlmess and modularity within NLS itself. The issue of distributive 
mo ularity has also influenced the control structures of MPS in that it 

NLS* n w trat r d J ha - S ? me f ° rm ° f para,,el control mechanism was essential if 
NLS* were to be implemented in this way. The capability for paratle 

control in turn suggested that "display correction" (the probfem of 
guaranteeing that what is displayed reflects accurately changes which occur 
m th. document being edited) might best be handled as a pseudo-parallel 

£f rh SS fr h '? h reacts to " al teration events" which may affect thecal idity 
the display contents. Since the contents of an NLS display include such 
pa rate items as the status of the current command specification the 
^i?? H d r e : h Var,OUS parameters indicating the "view" of the document as 

nice v el im!na^ U rh r 3 P ° r ? lon ° f th ® document itself, this approach 
nice y eliminates the very complex scheduling of display alterations 

Ih^r Jh" 9 " unc °nnected" events. A primary P r eIult of this view is 

and^th^H rapid y changing command status Indications, the displayed time 

h ^ OCUment d '? p,ay are a ” seen as display feedback and mal be 
handled in one consistent manner. y 

Experience with NLS in the ARPANET community has spotlighted the need for a 

oica iinal^rr tl a ?he a r I acM,ty a ccommodating everyone from the 
occasional user to the hard-core sophisticate and for allowinq users to 

* a ' ,or * he system to their individual tastes and tasks. NLS* will reolace 

facing bu ! t T' n c ° mmand recognizer of NLS with a more flexible system 
facility consisting of a data structure which describes a command language 


14 







the a fouX°Ju^s!' S " h ' Ch “ Se that SP ' Cifi ‘ a(, °"- Thp PTfon. 

^ Interpretation of a complete command to invoke the facilities of 
NLS: separating this function out provides part of the framework 
for a user-programmable NLS. 

(2) Recognition and feedback during user command specification: this 
helps accommodate various classes of users; beginners can get 
maximal feedback about commands and their options and even'be 
protected from "accidentally encountering" overly-complex 
commands; sophisticated users can choose a recognition algorithm 
which minimizes keypushes and still specify a feedback regime 

which gives adequate information about their interactions with the 
system. 

(3) Language definition and alteration: new commands can be added 
easily or a user can tailor a command language to his requirements 
by macro definition or by altering the data structure which 
defines the language. 

The need for many of these facilities has been so keenly felt that they are 
being added to the current NLS; they are described in [5]. Y 

IrLEilr!L da Jh d0m ! in f ° r NLS i$ t6Xt; Slmple 9 ra Phics, mixed text and 
g a Phics and other structures would be extremely useful. In order to 

raci1itate the addition of new types of data to the NLS world, NLS* will 

proviiie a single interfacing method for all data types. A datum which is 

to be manipulated by NLS will carry a tag specifying its type. This taq is 

used to select a specific action from an action class for a given 

operation. For instance, if the datum is to be displayed, the display 

a^d‘?nf f ° r J- at d K t3 tyP ®. ?S lnvoked with a suitable handle on the datum 
tht ! J '°l ab0llt 3 d,splay area in which it should be formatted. If 

disDlaJ rou?in« r X - d t6Xt a " d gra P hJcs " < MTG ) then the MTG 

display routine is invoked for it. Because of this approach, this routine 

Ca hri aC ^ aS ° ver ! ord for the text and graphics display routines and 

MTG daium Thir^ 91 di h PlaY ^ 9lV6n t0 hlm am ° n9 the com Ponents of the 
MTG datum. This approach appears very promising for combining primitive 

data types into more complex structures without duplicating the^aci 1 i t ies 

for each subtype simply because they are being used" in combination 
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Appendix A: NLS Protocol Command Formats 


This Appendix gives the protocol specifications in detail. Each command is 
headed by a phrase which identifies it, and the command is defined in a 
BNF-1ike notation; square brackets denote optional items, slashes divide 
alternatives, and parentheses are used to group alternatives. A "$ M 
preceding an element of a rule means "zero or more occurrences of" 

Numbers which are suffixed with a "B" represent octal numbers and occupy no 
more than seven bits, i.e. they fit in one transmitted byte. Any variables 
which can only be 0 or 1 occupy one bit and are usually packed together 
into a single byte. 

Each command arrives as a string of characters at the display, which must 
interpret the first two characters of the command in real time. The 
remaining characters in a message may be buffered until the entire message 
is received and then interpreted. There is, however, no requirement in the 
protocol that the entire message may not be interpreted as it arrives. 

There is no checksum or other error check as part of the command stream. 

command UnescortedChar/ESC CNT CommandTail; 

ESC :33B; -- the ESC or ALTMODE (ASCII) character identifies a 
command 

UnescortedChar ::= — any 7-bit character except ESC —; 

Unescorted characters are placed sequentially in the TTYSDA and in any 
default SDAs. 


CNT ::= — a number in the range [40B, 177B] — 

CNT is the (count of the number of bytes which are to follow in the 
message)+40B; this offset notation guarantees that the count cannot 
look like 33B (ESC) or any control character; hence commands and 
unescorted characters are readily distinguishable. 

Command tail ::= 


ada / 
dda / 
sdda / 
rdda / 


Allocate a Display Area 
Deallocate a Display Area 
Suppress Display of a Display Area 
Restore Display of a Display Area 


strda/ 
ssda / 
rsda / 
apsda/ 
echda/ 


STRing to a DA 

Suppress String in DA 

Restore String in DA 

Append String to Sequential DA (SDA) 

Specify SDA(s) for Unescorted Characters 


tsnda/ -- Teletype Simulation ON 

tsfda/ — Teletype Simulation OFF 
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scm / — Short Character Mode 

lcm / -- Long Character Mode 


scsr / 
ccnda/ 
ccfda; 


Specify Cursor String 

Continuous Coordinate Transmission ON 

Continuous Coordinate Transmission OFF 


Allocate a Display Area : 


ada ::= 
DAID ::= 
A LONGNUMBER 
order bytes 
LONGNUMBER i 


16B DA ID NSTRS NCHARS ATXY DY CSIZE HIMC FONT; 

LONGNUMBER; — a DAID is a 9“bit number which names a DA. 
is sent as two 8 bit bytes; if B1 and BO are the high and 
(they arrive in the order B1, B0) then the value v of a 


low 


v= 2+6 *((B1 mod 2+6M0B) + ((BO mod 2+6)-40B) 
thus, a LONGNUMBER is limited to the range [0,4095], 

NSTRS ::= SHORTNUMBER; 


A short number occupies the low order 7 bits of a bit and is therefore 
restricted to the range [0, 177B]. NSTRS defines the number of lines in 
the display area (i.e. its height). 


NCHARS SHORTNUMBER; — lines sent to this DA which contain more 

than NCHARS characters are to be broken into 
multiple 1ines. 

ATXY ::= XBOT YBOT; -- the coordinates of the lower left-hand corner of 

the DA. 


XBOT ::= LONGNUMBER; 

YBOT ::= LONGNUMBER; 

DY ::= LONGNUMBER; -- this is the height of a line in terms of basic 

display increments, and includes any blank space 
between lines. 

CSIZE 0/1/2/3; 


Specifies the default character size for the DA. CSIZE is a 
mapping value and all that is required is that characters of size i be 
greater than j-sized characters (i,j=0,1,2,3) for i>j. 

HINC ::= SHORTNUMBER; — specifies the width of characters in terms of 

basic display increments. Hence, fixed pitch fonts 
(all characters occupying equal width areas) are 
assumed. This includes the space between 
characters. 


FONT ::= 0 0 FOV FUL 
one-bit switches given, 
strings displayed in the 


FBO FIT FBL; — this is one byte composed of the 
FONT, CSIZE and HINC specify default values for 
DA. 
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The switches for FONT are defined as 


FOV 

:= 0/1; 

FUL 

:= 0/1; 

FBO 

:= 0/1; 

FIT 

:= 0/1; 

FBL 

:= 0/1; 


1=> overline displayed characters 
1 => underline displayed characters 
> display characters in boldface type 
1=> display characters in italic type 
1=> blink displayed characters on and off 


Deallocate a Display Area : 

dda ::= 2 DAID; 

The DA identified by DAID is deleted; it need not be empty when this 
command is sent: any strings in it will automatically be deleted first. 


Suppress Display of a DA : 

sdda ::= 6 DA ID KILLFLAG; 


The identified DA is turned off 
Additionally, if KILLFLAG =1, i 


(none of its contents are displayed), 
ts contents are destroyed. 


KILLFLAG- 0/1;—1=> delete; 0=> don't delete. 


Restore Display of a DA : 

rdda ::= 7 DAID; 

The contents of a previously suppressed DA are displayed (unless the 
previous sdda also deleted them, of course). 


String Manipulation in a DA : 

strda ::= 20B DAID STRID SLNGTH FRMT [ATXY] [HINC] [FONT] STRING; 

This command is used to introduce a new string, replace an existing string, 
or move an existing string from one position in a DA to another. 

STRID ::= SHORTNUMBER; 


STRID identifies the string; if it is a new string, it is given 
of STRID as its name; otherwise STRID is used to identify which 
the DA is to be manipulated. The value of STRID is independent 
(X,Y) position of the string. 


the value 
string in 
of the 


SLNGTH ::= SHORTNUMBER; 
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SLNGTH-0 means operate on the current string with name STRID; the actual 

<™!I!r’- STR ! NG ’ J? not .P r ® sent the command. SLNGTH=1 means "pretend 
7/' string"; STRING is not present in this case either. 
SLNGTH>1 means 'make the string STRING which is appended to this command be 
the one with name STRID If there already is a string with name STRID, it 
will be replaced by the STRING in the command. 

FRMT ;;= FORMATS + 40B; a single byte 
FORMATS ::= FDS FDD IDS IDD SDS SDD XYDS; 

FORMATS is a string of 7 bit switches which is sent in a single byte 
(offset by 40B). J 7 

• FDS 0/1;-- l-> use the value of FONT switches from the previous 
instance of STRID for the new instance; 

FDD ::= 0/1; — l=> use the DA default value for FONT switch values. 

FDS=FDD=0 means that FONT is present in the command. 

IDS ::= 0/1; 

IDD 0/1; 

IDS and IDD behave for HINC as FDS and FDD do for FONT 

SDS ::= 0/1; 

SDD 0/1; 

SDS and SDD behave for CSIZE as FDS and FDD do for FONT. 

XYDS ::= 0/1; 1=> use STRID's current coordinates. 

XYDS=0 means ATXY is present in the command. 

STRING $(SHORTNUMBER); — 0 or more 7-bit bytes (ASCII) which are the 
contents of the string if SLNGTH>1. 


Suppress String in DA : 

ssda ::= I0B DAID STRID KILLFLAG; 

Suppress the display of the named string in the given DA; if KILLFLAG=1 
also delete the string from the DA. Altering the display status of 
individual strings is overridden by the display status of the DA; if the DA 
is suppressed any displayed strings in it are suppressed also until the DA 

! . a9ai " turned on: i.e., the display status of each string is remembered 
independently of whether the DA is suppressed. 
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Restore String in DA : 


rsda 11B DAID STRID; 

Restore the named string in the given DA; whenever the DA is displayed the 
string will be displayed. 


Append String to Sequential DA : 

apsda ::= 17B DAID STRING 

The initial CNT field in the command header contains LENGTH(STRING )+3 to 
account for the characters 17B and the DAID (which is a LONGNUMBER). The 
string supplied is appended to the sequential display area. 

Carriage-return and linefeed must be simulated by the display to behave as 
they do for a teletype. Strings longer than the NCHARS parameter for the 
DA (see the "ada" command) are broken into an appropriate number of lines. 

A received + A (00IB) or + H (010B) character causes the last character in 
the SDA to be deleted (it should disappear from the screen so that the next 
character sent to the SDA will occupy the same screen position as the 
character just deleted. +W (027B) must delete any invisible characters 
from the current SDA position to the left until a visible character is 
encountered and then all the visibles from there up to (but not including) 
the next invisible character. The set of invisible characters are 
carriage-return (+M=0J5B), space (0**0B), and tab ( + 1-01 IB); visible 
characters are all the normal, printable ASCII characters exclusive of 
these invisibles. +G (007B) should simulate the bell on a standard TTY* if 
there is no "aural" indicator, the display should produce a bell symbol’ 

(e.g. the word ‘BELL!") which is overwritten by the next character 
displayed. 


Specify DA(s) for Receiv ing Un escorted Characters ; 

echda :;= 3 FLAGS [DAID1] [DAID2]; 

FLAGS ::= 0 AD SD A1 SI A2 S2; — seven one-bit fields in a 

single byte. 

AD=1 means unescorted characters go to TTYSDA; if SD=1, they will not. 

Al=l means unescorted characters should go to the DA identified by 
DAID1; SI means they should not; A1=S1=0 means DAIDI is not present. 

A2 and S2 mean the same for DAID2 as A1 and SI do for DAIDI. 

Unescorted characters, therefore, can go to three SDAs simultaneously if 

AD-AI-A2=1. Copies of the characters are made by the display and placed in 
each SDA. 
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Teletype Simulation On; 


tsnda ::= 12B; 

Turn on the current TTYSDA and suppress any other DAs which are currently 
on. 


Teletype Simulation Off : 

tsfda ::= 13B; 

Suppress the current TTYSDA and restore the DAs suppressed by the most 
recent tsnda command. 


Short Character Mode: 


scm ::= 15B 

Send only short characters to the MLS host (characters like tX, +D, etc. 
will be sent just as they would from a teletype). 


Long Character Mode : 

lcm ::= l^B; 

Send long characters to the NLS host when appropriate. (See the 
description of long characters in Section II "The NLS Protocol".) 


Specify Cursor String for Tracking the House : 

scsr ::= 05B SLNGTH CSIZE HINC FONT STRING 

The given string is to be displayed as the cursor which tracks the mouse 
(or other pointing device) on the screen. A detailed description of the 
parameters SLNGTH, CSIZE, HINC and FONT are given under the commands ada 
(Allocate Display Area) and strda (String to DA). For the scsr command, 
SLNGTH (=LENGTH(STRING)+1) must be greater than 1. 


Continuous Coordinate Transmission On: 


ccnda ::= 21B DT DXY; 

Mouse coordinates are to be sent to the NLS host every DT milliseconds, if 
either its x or its y coordinate has changed by more than DXY 
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DT ::= LONGNUMBER; 

DXY ::= LONGNUMBER; 

Mouse coordinates, as sent to the NLS host, have the form 

coord ::= BMSG kkB ATXY; 

BMSG = 34B; 

ATXY ::= XCOORD YCOORD; 

XCOORD ::= LONGNUMBER; 

YCOORD ::= LONGNUMBER; 


Continuous Coordinate Transmission Off : 

ccfda ::= 22B; 

Stop sending mouse coordinates continuously. 
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Appendix B: Keyset Chord/Character Correspondences 


The 

" 1 " 


mouse buttons are given as B2, Bl, BO and a 
indicates the corresponding button is depressed. 


House and Keyset, Codes and Cases 


House Buttons: 


Keyset Chord 
00001 
00010 
00011 
00100 
00101 
00110 
00111 
01000 
01001 
01010 
01011 
01100 
01101 
oino 
01111 
10000 
10001 
10010 
10011 
10100 
10101 
10110 
10111 
11000 
11001 
1 1010 
non 
11100 
11101 
11110 
mu 


000 010 loo 

a A J 

b B " 

C C # 

d D $ 

e E % 

f F & 

g G • 

h H ( 

1 I ) 

j j e 

k K + 

1 L 

m M * 

n N / 

o 0 t 

P P 0 

q Q 1 

r R 2 

s S 3 

t T b 

u U 5 

v V 6 

w W 7 

x X 8 

y Y 9 

z Z 

. < [ 

] 

; : 

^ \ ESC 

SP TAB CR 


23 














References 


[1] "Online Team Environment - Network Information Center and Computer 

Augmented Team Interactions", Augmentation Research Center, 
Stanford Research Institute, NIC #13041. 


[2] Deutsch, L. P., "A LISP Machine with Very Compact Programs", in 

Proceedings of the Third International Joint Conference on 
Artificial Intelligence, Aug. 1973, PP« 697”703« 


[3] "User's Reference Manual, IMLAC PDS-1 Programmable Display 
System", IMLAC Corp., 1970. 

[4] Dornbush, C. F., Irby, C. H., Mitchell, J. G., "A Look at the MPS 
Conversion", NIC #15376. 


[5] Irby, C. H., "Proposed Changes in the NLS Command Language", 

August, 1973, NIC #18408. 


[6] Mitchell, J.G., "MPS Segmentation System", MPS Group internal 

document, Jan. 1972, available currently as NIC #19734. 


24 










